# 처리량 최적화 (Throughput Optimization)

## 1. 개요

### 1.1 정의
**처리량(Throughput)**이란 단위 시간당 시스템이 성공적으로 처리하여 완료한 작업의 양을 의미합니다. 시스템 성능 측정에서 처리량은 전체적인 생산성과 처리 능력을 나타내는 핵심 지표입니다.

이때 **시스템 처리 용량(Capacity)**은 시스템이 이론적으로 처리할 수 있는 최대 한계를 의미하며, **실제 처리량(Actual Throughput)**은 현재 부하 상황에서 실제로 처리되고 있는 양을 의미합니다. 처리량 최적화의 목표는 단순히 수치를 높이는 것이 아니라, **목표 서비스 수준(SLA, Service Level Agreement)을 만족하는 지연 시간 범위 내에서 최대 처리량을 확보**하는 것입니다.

### 1.2 처리량과 지연 시간(Latency)의 차이
많은 경우 처리량과 지연 시간을 혼동하지만, 두 개념은 서로 다른 관점에서 성능을 측정합니다.

*   **지연 시간(Latency):** 하나의 요청이 시작되어 완료될 때까지 걸리는 시간(응답 시간)을 의미합니다. (단위: ms, sec)
*   **처리량(Throughput):** 정해진 시간 동안 처리된 총 요청의 수입니다. (단위: TPS, RPS)

**상관관계:** 일반적으로 지연 시간이 짧을수록 처리량이 증가할 가능성이 높지만, 항상 비례하는 것은 아닙니다. 예를 들어, 큐(Queue)를 도입하여 요청을 쌓아두면 개별 요청의 지연 시간은 늘어나지만, 시스템이 쉬지 않고 작동하게 하여 전체 처리량은 높일 수 있습니다.

---

## 2. 처리량 저하의 주요 원인 (Bottleneck)
**병목 현상(Bottleneck)**이란 시스템의 여러 구성 요소 중 가장 성능이 낮은 지점이 전체 시스템의 최대 처리량을 제한하는 현상을 말합니다.

### 2.1 자원별 병목 지점 분석
| 자원 | 주요 병목 증상 | 진단 방법 및 도구 |
| :--- | :--- | :--- |
| **CPU** | CPU 사용률 100% 근접, 컨텍스트 스위칭 과다 발생 | `top`, `htop`, `vmstat` (CPU Load Average 확인) |
| **메모리** | Swap 영역 사용 증가, 빈번한 GC(Garbage Collection) 발생 | `free`, `vmstat`, JVM 모니터링 툴 (Heap Memory 분석) |
| **디스크 I/O** | I/O Wait 수치 상승, 디스크 큐 길이 증가 | `iostat`, `iotop` (Disk Utilization 확인) |
| **네트워크** | 패킷 손실(Packet Loss), 대역폭(Bandwidth) 포화 | `netstat`, `iftop`, `tcpdump` (Network Traffic 분석) |

---

## 3. 입출력(I/O) 최적화 전략
I/O 작업은 CPU 연산 속도에 비해 매우 느리기 때문에, I/O 대기 시간을 최소화하는 것이 처리량 최적화의 핵심입니다.

### 3.1 주요 최적화 기법
1.  **버퍼링(Buffering):** 데이터를 작은 단위로 자주 전송하는 대신, 메모리 상의 버퍼에 모았다가 한 번에 전송하여 I/O 횟수를 줄이는 기법입니다.
2.  **캐싱(Caching):** 반복적으로 요청되는 데이터를 고속 메모리(Redis, Memcached 등)에 저장하여 디스크 접근이나 네트워크 호출을 생략하는 기법입니다.
3.  **비동기 I/O(Asynchronous I/O):** I/O 요청 후 결과가 올 때까지 기다리지 않고 다른 작업을 수행하다가, 작업이 완료되면 콜백(Callback)이나 이벤트로 통지받는 방식입니다.

### 3.2 코드 예제: 동기 vs 비동기 처리 방식 (Pseudo-code)

**[동기 방식 (Synchronous)]**
```python
# 요청마다 I/O 완료를 기다림 (처리량 낮음)
for request in requests:
    response = call_external_api(request) # 여기서 블로킹 발생
    save_to_db(response)
```

**[비동기 방식 (Asynchronous)]**
```python
# I/O 요청을 던지고 다른 작업을 수행 (처리량 높음)
import asyncio

async def process_request(request):
    response = await call_external_api_async(request) # 비동기 대기
    await save_to_db_async(response)

async def main():
    # 여러 요청을 동시에 스케줄링
    # 주의: 실제 적용 시에는 Semaphore 등을 사용하여 동시 실행 수를 제한해야 함.
    # 제한 없이 수만 개의 요청을 gather로 처리할 경우 리소스 고갈(Too many open files 등)이 발생할 수 있음.
    await asyncio.gather(*(process_request(r) for r in requests))
```

---

## 4. 병렬 처리 및 확장 전략
단일 스레드/프로세스 구조에서는 하드웨어 자원을 충분히 활용할 수 없으므로, 작업을 분산하여 동시에 처리하는 전략이 필요합니다.

### 4.1 처리 모델 비교
*   **멀티스레딩(Multi-threading):** 하나의 프로세스 내에서 여러 스레드를 생성하여 공유 메모리를 통해 빠르게 통신하며 작업을 처리합니다.
*   **멀티프로세싱(Multi-processing):** 여러 개의 독립적인 프로세스를 생성하여 CPU 코어별로 작업을 분배합니다. GIL(Global Interpreter Lock)이 있는 언어(Python 등)에서 CPU 집약적 작업을 처리할 때 필수적입니다.
*   **이벤트 루프(Event Loop):** 싱글 스레드 기반으로 비동기 이벤트를 처리하는 모델입니다. (예: Node.js) I/O 바운드 작업이 많은 시스템에서 효율적입니다.

### 4.2 시스템 확장 방식 (Scaling)
시스템의 처리 용량을 늘리기 위해 하드웨어 자원을 추가하는 방법은 크게 두 가지로 나뉩니다.

| 구분 | 수직 확장 (Scale-up) | 수평 확장 (Scale-out) |
| :--- | :--- | :--- |
| **개념** | 기존 서버의 사양(CPU, RAM, SSD)을 높임 | 서버 대수를 늘려 부하를 분산함 |
| **장점** | 아키텍처 변경 불필요, 데이터 일관성 유지 용이 | 이론상 무한 확장 가능, 고가용성(HA) 확보 |
| **단점** | 하드웨어 한계 존재, 비용 급증, 단일 장애점(SPOF) | 로드 밸런싱 필요, 데이터 동기화/일관성 복잡도 증가 |
| **적합 사례** | 데이터 일관성이 극도로 중요한 DB 서버 | 웹 애플리케이션 서버, 마이크로서비스(MSA) |

### 4.3 로드 밸런싱(Load Balancing) 아키텍처
수평 확장 구조에서는 여러 대의 서버로 트래픽을 분산하는 로드 밸런서가 필수적입니다.

```mermaid
graph LR
    Client --> LB[Load Balancer L4/L7]
    LB --> ServerA[Server A]
    LB --> ServerB[Server B]
    LB --> ServerC[Server C]
    ServerA --> CacheDB[(Distributed Cache/DB)]
    ServerB --> CacheDB
    ServerC --> CacheDB
```

---

## 5. 데이터 처리 효율화
전송되는 데이터의 양을 줄이거나 처리 단위를 최적화하여 효율을 높입니다.

### 5.1 최적화 기법
*   **배치 처리(Batch Processing):** 데이터를 실시간으로 하나씩 처리하지 않고, 일정량 또는 일정 시간 동안 모아서 한 번에 처리하여 네트워크 오버헤드와 DB 커밋 횟수를 줄입니다.
*   **데이터 압축 및 직렬화:** JSON 대신 Protocol Buffers, Avro, MessagePack과 같은 이진(Binary) 직렬화 형식을 사용하여 페이로드 크기를 줄이고 파싱 속도를 높입니다.
*   **페이징 및 필터링:** API 응답 시 필요한 데이터만 선택적으로 반환(Filtering)하거나, 대량의 데이터를 나누어 전송(Paging)하여 단일 요청의 부하를 줄입니다.

### 5.2 실시간 처리 vs 배치 처리 비교
| 구분 | 실시간 처리 (Real-time) | 배치 처리 (Batch) |
| :--- | :--- | :--- |
| **처리 단위** | 개별 이벤트/메시지 단위 | 대량의 데이터 묶음 단위 |
| **응답 속도** | 매우 빠름 (Low Latency) | 느림 (High Latency) |
| **처리량** | 상대적으로 낮음 | 매우 높음 (High Throughput) |
| **적합 사례** | 결제 승인, 채팅, 실시간 알림 | 일일 정산, 로그 분석, 데이터 백업 |

---

## 6. 성능 측정 및 모니터링
처리량 최적화의 결과는 객관적인 지표와 도구를 통해 검증되어야 합니다.

### 6.1 핵심 성능 지표 (KPI)
*   **TPS (Transactions Per Second):** 초당 처리되는 트랜잭션 수.
*   **RPS (Requests Per Second):** 초당 처리되는 HTTP 요청 수.
*   **Error Rate:** 전체 요청 중 실패한 요청의 비율.

### 6.2 처리량 측정 및 부하 테스트 도구
| 도구 | 특징 | 주요 용도 |
| :--- | :--- | :--- |
| **JMeter** | Java 기반의 전통적인 강력한 도구, 다양한 프로토콜 지원 | 복잡한 시나리오 기반의 성능 테스트 |
| **k6** | Go로 작성되고 JS로 스크립팅, 가볍고 현대적인 CLI 도구 | CI/CD 파이프라인 통합, 개발자 친화적 테스트 |
| **nGrinder** | Naver 개발, Groovy 스크립트 사용, 관리 GUI 제공 | 분산 부하 테스트 및 결과 시각화 |
| **Locust** | Python 기반, 코드 중심의 테스트 정의, 확장성 높음 | 동시 사용자 시뮬레이션 및 커스텀 로직 구현 |

### 6.3 최적화 사이클
`가설 설정` $\rightarrow$ `부하 테스트(JMeter, k6, nGrinder)` $\rightarrow$ `병목 지점 분석(APM 툴)` $\rightarrow$ `코드/설정 최적화` $\rightarrow$ `재검증`

### 6.4 최적화 전후 성능 비교 예시
| 지표 | 최적화 전 (Baseline) | 최적화 후 (Optimized) | 개선율 |
| :--- | :--- | :--- | :--- |
| 평균 처리량 (TPS) | 500 TPS | 2,500 TPS | 400% $\uparrow$ |
| 평균 지연 시간 | 200ms | 120ms | 40% $\downarrow$ |
| CPU 사용률 (Peak) | 95% | 60% | 35% $\downarrow$ |
| 최대 동시 접속자 수 | 1,000명 | 5,000명 | 400% $\uparrow$ |

---

## ⚠️ 처리량 최적화 시 주의할 부작용
처리량을 높이기 위한 시도가 항상 긍정적인 결과만을 가져오는 것은 아니며, 다음과 같은 트레이드-오프(Trade-off)를 고려해야 합니다.

1.  **메모리 사용량 증가:** 캐싱과 버퍼링을 과도하게 사용할 경우 메모리 부족(Out of Memory) 현상이 발생하여 시스템 전체가 다운될 수 있습니다.
2.  **데이터 일관성 문제:** 비동기 처리나 분산 캐시를 도입하면 데이터의 최신 상태가 즉각 반영되지 않는 '최종 일관성(Eventual Consistency)' 문제가 발생할 수 있습니다.
3.  **복잡도 증가:** 멀티스레딩 도입 시 데드락(Deadlock)이나 레이스 컨디션(Race Condition)과 같은 동시성 제어 이슈가 발생하여 디버깅 난이도가 급격히 상승합니다.
4.  **하위 시스템 과부하:** 애플리케이션 서버의 처리량을 높였으나, 하위 데이터베이스(DB)의 연결 수(Connection Pool)가 부족할 경우 DB 서버에 과부하가 집중되어 시스템 전체가 마비될 수 있습니다.